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REVELATIONS IN NETWORK HOST MEASUREMENTS 


The purpose of RFC 392 was to identify a probiem we had en- 
countered in using the ARPANET at Utah. The primary thrust of 
the paper was supposed to be: "Here is a place to make the 
Network better" rather than: "Look, isn't the Network terrible." 
The accepted use of 392 seems to be the latter rather than the 
former. A second purpose of 392 was to stimulate he undertaking 
of measurement experiments on other computers and operating 
systems in addition to TENEX. Very little in the way of 
itecurements has been reported (other than Hal Murray's RFC 415 
measuring TENEX). 

Since the Publication of RFC 392, BBN has done a considerable 
amount of work to improve Host-Net performance on TENEX. They 
reported new measurement results in their April 1973 Quarterly 
Progress Repert No. 10. I feel it is important to circulate 
those results to the RFC community. 

Don Allen at BBN borrowed Greg Hicks! RJS program and 
1) updated it to take advantage of recent changes in TENEX, 

2) improved the code near the Yapueyoucput JSYs and 3) used 
considerably faster network monitor code. The result was 
approximately 400% improvement from 75-85 secede of CPU time 
per megabit (%$10) to 19 seconds per megabit (%$2.50). Of the 
19 seconds, 13 were spent in the RJS program and 6 in TENEX net- 
work output. The six seconds seem to relate very well to BBN 


FTP measurements where 8.2 cpu seconds per megabit were required 
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(v$1.08) for 8 bit byte transfers. (Going to 32 or 36 bit 
bytes improves this figure by a factor of 4, resulting in a 
cost of $.33 per ER E 

Of the 13 seconds left in RJS no attempt was made to improve 
or even discover where the time was spent. This extra effort 
was not expended because RJS is soon to be replaced by the RJE 
protocol which uses FTP as its transfer mechanism. 


In summary, I believe that the original RFC #392 and the 


Pad 


recent BBN results show that the Network, including the Host 
cost, is intrinsically effective. If care is not taken in 
monitor and user code the system may not look very attractive. 
I hope everyone now goes out and measures how good (or bad) they 
are doing vis 4 vis network transfers. Please send me the re- 
sults personally if they are too embarrassing to distribute via 
RFC. It would be nice to hear from all systems. 

All the data is courtesy of Don Allen and Jerry Burchfiel 


at BBN. 


